Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/command/web.go`:
- Around line 444-473: The breakdownFn closure reads shared mutable state
(systemPrompt, mcpTools, currentCM, and skillLoader) without synchronization,
creating a data race risk in the concurrent web server environment. Protect
access to these shared variables by acquiring an appropriate synchronization
lock (such as a mutex) before reading them within the breakdownFn function, and
release the lock after gathering all necessary data for the breakdown
calculation. Ensure that the entire set of reads happens atomically while
holding the lock to prevent torn or inconsistent state from being observed
during concurrent project switches or MCP reloads.
- Around line 449-471: The breakdownFn function always estimates context tokens
using systemPrompt and buildAllTools(currentCM), but it should dynamically
select between systemPrompt with buildAllTools(currentCM) for normal mode versus
planPrompt with buildPlanTools() for plan mode. Update the breakdownFn function
to check if plan mode is active and use the appropriate prompt and tools
building function to accurately reflect the actual context being used by the
agent in the current mode. This will ensure b.SystemPromptTokens and
b.SystemToolsTokens are correctly calculated regardless of whether plan mode is
enabled.

In `@internal/config/config.go`:
- Around line 455-458: The fmt.Errorf call in the error handling block after
os.UserHomeDir() is not following the project convention for wrapped errors.
Replace the current free-form error message "failed to get home directory: %w"
with the standard format "tool_name: %w" (where tool_name is the appropriate
identifier for this module), maintaining the wrapped error pattern with %w and
the captured err variable.

In `@internal/model/chatmodel.go`:
- Around line 161-164: The CacheObserved() method in TokenUsage incorrectly uses
CachedTokens count as the indicator for whether cache support was detected, but
this conflates actual cache hits with cache reporting capability. A provider may
report caching metadata but have zero cache hits in a session, which should
still count as cache being observed. Refactor CacheObserved() to check a
separate flag or counter that tracks whether caching information was ever
reported by the provider, independent of the actual cached token count. Also
apply the same fix to any related cache observation logic in the 280-301 line
range, ensuring all cache support detection is based on whether the provider
reports caching data rather than on whether cached tokens are greater than zero.

In `@internal/team/manager.go`:
- Around line 757-775: The usage.Event being recorded in the token delta
tracking is missing proper population of the Model and Project fields. The Model
field relies on state.Model which can be empty on the default-model path, and
Project is not set at all, causing analytics to drop these records from by_model
and by_project breakdowns. Enhance the usage.RecordEvent call by ensuring Model
has a fallback value when state.Model is empty and add the Project field to the
usage.Event struct with the appropriate project information, likely obtained
from the manager's dependencies or team state context.

In `@internal/tools/subagent.go`:
- Around line 351-365: The event recording in the RecordEvent call is being
gated by a check that requires d.TotalTokens to be greater than zero, which
prevents recording valid usage data from providers that omit the total_tokens
field while still reporting other token values like prompt or completion tokens.
Remove or modify the if d.TotalTokens > 0 condition to instead check if any of
the individual token fields (PromptTokens, CompletionTokens, CachedTokens,
ReasoningTokens, CacheWriteTokens, or CallCount) have non-zero values, ensuring
that usage events are recorded whenever there is meaningful token usage data
available regardless of whether TotalTokens is present.

In `@internal/usage/stats.go`:
- Around line 93-103: The CacheSupported flag in the aggregation logic is being
set based on whether Cached tokens are greater than zero, but it should instead
be determined by whether cache fields are actually reported by the provider,
regardless of hit count. Remove the current logic that sets CacheSupported =
agg.Totals.Cached > 0 and implement an explicit tracking mechanism (such as a
boolean field that is OR-aggregated across all events) to record whether cache
fields were observed in the data, then use that aggregated signal to determine
CacheSupported instead of inferring it from the Cached value.
- Around line 170-191: The longestStreak function initializes the best variable
to 1, which causes it to return a non-existent streak of length 1 when all date
parsing fails and the dates slice is empty. Change the initialization of the
best variable from 1 to 0 so that when the dates slice is empty (meaning all day
keys failed to parse), the loop does not execute and the function correctly
returns 0 instead of reporting a false streak.

In `@internal/web/usage.go`:
- Around line 133-134: The store.Load function call is ignoring its error return
value using a blank identifier, which masks I/O and corruption problems. Instead
of discarding the error with _, check the error returned from store.Load("") and
handle it appropriately by either logging the error and returning early or
implementing suitable error recovery logic that prevents the function from
continuing with uninitialized or incorrect data.

In `@web/src/components/ChatInput.vue`:
- Around line 29-36: The ctxRingColor computed property uses a hardcoded hex
color value `#E24B4A` for the warning state when token percentage is >= 90, which
violates the color-token contract. Replace this hardcoded hex value with an
appropriate CSS custom property (design token) from src/styles/tokens.css that
represents a warning or error state color. Update the ctxRingColor computed
property to reference this design token using var() syntax instead of the
literal hex value.

In `@web/src/components/ContextCapacityPopup.vue`:
- Line 144: The box-shadow property in ContextCapacityPopup.vue contains a
hardcoded RGBA color fallback value (rgba(0, 0, 0, 0.16)) which violates the
tokenized theme contract. Replace the hardcoded rgba color value in the
box-shadow fallback with a CSS custom property token defined in
src/styles/tokens.css. If a suitable shadow token does not already exist, add a
new token to the tokens.css file that defines the appropriate shadow value, then
reference that token in the var() function fallback instead of the hardcoded
color.

In `@web/src/components/UsageStatsPanel.vue`:
- Around line 141-145: The hardcoded "tokens" unit string in the cellTitle
function is not localized and will remain in English regardless of locale
changes. Replace the hardcoded "tokens" string with a translation reference
using the i18n pattern (similar to how `t('settings.usageStats.turnsUnit')` is
used for the turns unit). Create a new i18n key like
`settings.usageStats.tokensUnit` and update both the cellTitle function and the
other locations mentioned in lines 151-153 to use this localization key instead
of the hardcoded English string.

In `@web/src/stores/usage.ts`:
- Around line 18-25: In the fetchTaskStats function, the previous taskStats
value remains visible until the new API request completes, causing stale data to
display when switching sessions. To fix this, clear the taskStats value to null
immediately after setting taskLoading.value to true and before making the
api.taskStats call, ensuring no stale data is shown while the new session's data
is being fetched.

---

Nitpick comments:
In `@internal/usage/event.go`:
- Around line 92-98: The os.MkdirAll and os.OpenFile error returns lack
operation and path context, making it difficult to diagnose stats-store
failures. Wrap both error returns using fmt.Errorf with the %w verb to include
context about the failing operation and the path being accessed (s.path). For
the os.MkdirAll error, describe the directory creation failure with the path,
and for the os.OpenFile error, describe the file opening failure with the path.
Apply the same wrapping pattern to the similar filesystem operations around
lines 111-117 to ensure consistent error handling throughout.

In `@internal/web/usage_test.go`:
- Around line 172-212: Add a test case to verify error handling when the usage
Store.Load operation fails. Create a scenario where the Store encounters a load
error (by mocking or stubbing the Store to return an error), call
handleTaskStats with this failing store, and then assert that the HTTP response
returns an appropriate error status code and error details in the response body
to prevent silent failures on load errors.